Authentication for a commercial transaction using a mobile module

ABSTRACT

Current embodiments provide for authorization and payment of an online commercial transaction between a purchaser and a merchant including verification of an identity of the purchaser and verification of an ability of the purchaser to pay for the transaction, where the identity provider and the payment provider are often different network entities. Other embodiments also provide for protocols, computing systems, and other mechanisms that allow for identity and payment authentication using a mobile module, which establishes single or multilevel security over an untrusted network (e.g., the Internet). Still other embodiments also provide for a three-way secure communication between a merchant, consumer, and payment provider such that sensitive account information is opaque to the merchant, yet the merchant is sufficiently confident of the consumer&#39;s ability to pay for requested purchases. In yet another embodiment, electronic billing information is used for authorization, auditing, payment federation, and other purposes.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/379,143 filed on Apr. 18, 2006, entitled “AUTHENTICATION FOR ACOMMERCIAL TRANSACTION USING A MOBILE MODULE,” which issued as U.S. Pat.No. ______ on ______, which is both (1) a continuation of U.S. patentapplication Ser. No. 11/379,133 filed on Apr. 18, 2006, entitled SECURENETWORK COMMERCIAL TRANSACTIONS by Johnson, et al., as well as (2) acontinuation-in-part of U.S. patent application Ser. No. 11/376,535filed Mar. 15, 2006, entitled “METHOD AND APPARATUS FOR NETWORKTRANSACTIONS”, by Johnson, which issued as U.S. Pat. No. 7,849,020 onDec. 7, 2010, and both of which claim the benefit of U.S. ProvisionalApplication 60/672,754, filed Apr. 19, 2005, entitled “METHODS ANDAPPARATUS FOR NETWORK TRANSACTIONS.” All of the foregoing applicationsare incorporated herein by reference in their entireties.

BACKGROUND OF THE INVENTION

1. The Field of the Invention

The present invention relates to networked transaction systems andmethods for conducting online transactions.

2. Background

The proliferation of networked computer systems has opened up newpossibilities with respect to how corporations and individuals conductbusiness. For example, end-users connected to a network, (e.g., theInternet), via a networked device such as a computer, PDA, cellularphone, etc., may conduct commercial transactions over the network topurchase services and/or merchandise, conduct financial transactions, orotherwise conduct business or perform personal transactions over thenetwork. An inherent problem linked with online transactions issecurity, particularly when the transfer of moneys, funds and/orfinancial, personal or other confidential information is involved in thetransaction.

Many conventional online transactions are conducted according to one oftwo different, but related, models. Both models employ a browser as theinterface for handling information transfer between parties involved inthe transaction. In the first model, a merchant offers goods or servicesonline via a browser. The term “merchant” refers herein generally to anyentity offering goods and/or services for purchase. The term merchant isnot used to describe any particular commercial status or to describe alicensed seller, unless specifically stated. Rather, the term describesgenerically any seller or entity offering good and/or services forpurchase or sale. The term service provider is used hereininterchangeably with the term merchant and, unless otherwise stated,have the same meaning.

In a conventional online transaction, a merchant may have a website thatdescribes, displays or otherwise offers goods and/or services for sale.An end-user indicates a desire to purchase one or more goods orservices, typically by selecting the item via the browser interface. Thebrowser then displays a transaction page that allows the end-user toselect one or more payment types and to input information needed tocomplete the transaction. For example, the transactional page displayedby the browser may permit the end-user to select a payment type, such ascredit card (e.g., VISA, MasterCard, American Express, etc.) and toinput transactional information such as credit card number, cardexpiration date, etc. The transactional page may also query the end-userfor personal information such as name, billing address, shippingaddress, etc. The end-user then submits the information and the merchantprocesses the submitted information.

In this first model, the merchant typically “owns” the website. That is,the merchant maintains the website, is responsible for the content, andreceives and processes the transactional information provided by theend-user. The merchant may establish an account with the end-user beforeconducting the first transaction and the end-user may then access thataccount via a user established login and password each time the end-userconducts a transaction with the merchant. That is, the end-usertypically chooses a login name and a password to be used in subsequentsessions or transactions. After the end-user has submitted theinformation queried by the transactional page(s), the merchant processesthe information to make sure the information is sufficient to completethe transaction. For example, the merchant may ensure that the creditcard number is valid and has sufficient funds to cover the cost of thegoods and/or services.

The second model typically includes a third party transaction providerthat handles the payment portion of the transaction. The third partyforms a relationship with both the end-user and the merchant. Inparticular, the end-user may establish an account with the third partythat can be accessed via a login and password as discussed above. Toestablish the account, the end-user may provide personal and paymentinformation to the third party (i.e., the end-user may provide personalinformation identifying the user and payment information such as one ormore credit card numbers, expiration dates, etc.) The end-user may alsoestablish an electronic funds account by providing money to the thirdparty transaction provider, the balance of which can be used to purchaseonline goods and/or services. The third party archives the accountinformation provided by the end-user and/or maintains the end-user'sbalance.

The third party also establishes a relationship with the merchant,wherein the third party handles the payment processing of thetransaction. In particular, the third party agrees to make payments tothe merchant when an end-user with an account requests a transfer offunds to make a purchase. The merchant may provide the option of usingthe third party by signaling the availability of this option on itswebsite where the goods and services are being sold. For example, when auser visits a merchant's website and decides to make a purchase, theuser may then be presented with an option to pay for the purchase usingthe third party transaction provider.

When the end-user selects the option to pay for the purchase using thethird party transaction provider, the end-user's browser is redirectedto a website belonging to the third party transaction provider. Theend-user then logs into his/her account via the login/passwordcombination and selects a payment type (e.g., credit card) to use in thetransaction, or requests a transfer of funds from the user's fundsaccount to the merchant's account. Once the merchant determines thatpayment has been transferred appropriately by the transaction provider,the merchant can proceed to ship the purchased product or provide thepurchased service to the end-user. In the second model, the third partyis responsible for maintaining end-user personal and financialinformation and for processing the transaction.

BRIEF SUMMARY

Conventional online transactions, for example, the purchase of goodsand/or services over a network, are vulnerable to security breachesresulting in loss of personal, financial and/or other confidentialinformation. Moreover, in an untrusted network (e.g., the Internet),both merchants and purchasers are at risk for entering into atransaction with a bad actor such that one side of the bargain is notupheld. Conventional online transaction models may also require amerchant to archive purchaser's confidential information and may requirethem to handle payment aspects of the transaction. In addition,conventional online transaction models are awkward for the purchaser andproduce a generally unintuitive transaction experience. For example,conventional online transactions are conducted via a browser using alogin/password paradigm that is confusing and difficult to manage.

Applicant has identified and appreciated that delegating at least someof the transactional responsibilities handled by the purchaser andbrowser in conventional models to lower level systems (and away from thebrowser and end-user), may facilitate a simpler and more secure onlinecommercial transactions framework. For example, one or moretransactional tasks may be handled by the operating system at one orboth of the end-user and merchant, where information may be moresecurely safeguarded. By embedding one or more tasks in the operatingsystem, users may be relieved of some of the burden of transferringtransactional information, making the experience more intuitive andenhancing security. Moreover, the merchant may be relieved ofmaintaining purchaser information, handling of payment informationand/or processing the transaction.

Applicant has further appreciated that problems associated withvalidating the identity of a purchaser may be mitigated by exploitingtechnologies more secure and convenient than the login/password model.In one embodiment, identity information about a purchaser is provided bya subscriber identity module (SIM) card which stores identityinformation about the end-user that can be issued programmatically,creating a less confusing and more straightforward purchasingexperience. Moreover, embodiments herein provide for protocols, methods,computing systems, and other mechanisms configured for single ormultilevel authentication using a SIM device over an otherwise untrustedor unsecure network (e.g., the Internet).

Applicant has further appreciated that providing various transactionalelements of online commercial transactions using generally disinterestedthird parties mitigates risks involved for both the purchaser and themerchant. In one aspect of the invention, a commercial transactionsystem is provided wherein a first network entity provides verificationof a purchaser's identity and a different network entity providesverification of a user's ability to pay for the purchase, such that amerchant and a purchaser that are strangers to one another may conduct atransaction in relative security.

Still other embodiments allow for a three-way secure commercialtransaction between a merchant, consumer, and payment provide in such away that sensitive billing account information is opaque to the merchantor third parties. In such an embodiment, payment tokens are passed viathe consumer between the merchant and payment provider. Such paymenttokens are encrypted or signed in such a way that the merchant andothers do not control or obtain any sensitive account information forthe consumer. Nevertheless, the merchant can still confidently validatethe payment token indicating the consumer's ability to pay for servicesand/or goods provided.

In another embodiment, electronic billing information is used forpayment authorization, auditing, and other purposes. In this embodiment,various network entities (e.g., the consumer, merchant, paymentprovider, etc.) are provided with a machine readable electronic bill,which is used to automatically request and validate payment, create atransaction history, present a more accurate description of paid forservices/goods, and for other purposes in an online commercialtransaction. This billing information may also be used for paymentfederation of a single payment from a consumer to various businessassociates for the merchant. For example, the merchant may have acontractual relationship with various business associates that provideservices and/or goods in the commercial transaction. The electronicbilling information can include those portions of payments that are tobe distributed among the various associates such that payment federationcan automatically occur without any need for user interaction orseparate auditing and payment mechanisms.

Provided herein are also mechanisms for automated decisions of acommercial transaction using rules or constraints defined by any numberof network entities including the consumer, merchant, payment provider,etc. For example, payment options accepted by the merchant may becompared with payment options available to the consumer. Based on suchcomparison, the consumer may be presented only with those options thatmatch. Alternatively, the payment option may automatically be chosenbased on such comparison and/or based on additional rules orconstraints. For instance, the consumer may limit the type of paymentsbased on an established trust with the merchant. Of course, there may bemany other types of rules and/or constraints that determine variousactions that can occur in the commercial transaction.

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be obvious from thedescription, or may be learned by the practice of the invention. Thefeatures and advantages of the invention may be realized and obtained bymeans of the instruments and combinations particularly pointed out inthe appended claims. These and other features of the present inventionwill become more fully apparent from the following description andappended claims, or may be learned by the practice of the invention asset forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1 illustrates a block diagram of a networked computer system forperforming online transactions, in accordance with one embodiment of theinvention;

FIG. 2 illustrates a diagram of a system and method for initiating andperforming identity verification in an online transaction, in accordancewith one embodiment of the invention;

FIG. 3 illustrates a diagram of a system and method for performingpayment negotiation, verification and/or certification in an onlinetransaction, in accordance with one embodiment of the invention;

FIG. 4 illustrates a networked computer system for conducting onlinetransactions, wherein transactions are handled, at least in part, bytransaction software installed on computers connected to the network, inaccordance with one embodiment of the present invention;

FIG. 5 illustrates a networked computer system for conducting onlinetransactions, wherein transactions are handled, at least in part, bytransaction software installed on computers connected to the network, inaccordance with another embodiment of the present invention;

FIG. 6 illustrates a networked computer system for conducting licensingfor applications installed on an end-user computer, wherein the licenseis obtained via an online transaction, in accordance with one embodimentof the present invention;

FIG. 7A illustrates a system used for authenticating a mobile module toa network for establishing a secure communication therewith inaccordance with example embodiments;

FIG. 7B illustrates a system used for authenticating a user to a networkusing a mobile module when establishing a secure communication channelin accordance with example embodiments;

FIG. 7C illustrates a system configured for single or multilevelverification of various different services using a mobile module inaccordance with example embodiments;

FIG. 8 illustrates a three-way secure exchange of payment informationand payment federation in accordance with example embodiments;

FIG. 9 illustrates various uses of a commercial transaction subsystemand bill presentation in accordance with example embodiments;

FIG. 10 illustrates the use of payment options and rules for determiningwhat type of payment provider should be used for a commercialtransaction in accordance with example embodiments; and

FIG. 11 illustrates a subscriber identity module (SIM) device configuredwith a firewall for conforming to established radio networkcommunication protocols when used for commercial transactions inaccordance with example embodiments.

DETAILED DESCRIPTION

Conventional models for networked commercial transactions focus on thebrowser as the interface for requesting and submitting personal andfinancial information between an end-user purchaser and a merchant orservice provider, whether it be directly through the merchant or via athird party transaction provider. In the first instance, the merchant isburdened with creating and maintaining an infrastructure capable ofquerying, obtaining, handling and processing personal and financialinformation, typically with some minimum level of security. Moreover,the merchant may be responsible for maintaining accounts and accountinformation for each of its customers (which typically includes bothconfidential personal and financial information).

A purchaser must relinquish personal information (e.g., name, address,phone number, etc.) and financial information (e.g., debit and creditcard numbers and expiration dates, banking account numbers, etc.) tocomplete a transaction. At some level, the purchaser must trust that themerchant is an honest broker and will operate in good faith, using theinformation only as authorized. Likewise, a merchant must trust that apurchaser is who he/she represents and that the payment informationprovided is truly associated with the end-user making the purchase.There may be no sure way for a merchant to validate the identity of thepurchaser and/or the validity of the payment information. In adistributed networked environment, purchasers may have to rely on thereputation of the merchant, which may limit the sources from which thepurchaser is willing to conduct transactions. The merchant may have tooperate with even less conviction that the purchaser is a good faith,bone fide purchaser. In an untrusted network, this model may presentundue risks on one or both parties.

Even when an established and merited trust has developed between apurchaser and a merchant, databases storing customer informationmaintained by the merchant may be susceptible to hacking, informationtheft and even bad actors within an otherwise honest and trustworthybusiness. Third party transaction providers are also susceptible toelectronic theft, security breaches, etc. More sophisticated “spy-ware”programs allow hackers to record keystrokes and obtain screen shots ofcomputers that have been compromised, making browser based transactionsparticularly vulnerable to electronic theft. Accordingly, purchasersconducting online commercial transactions according to conventionalmethods and models may be vulnerable to dissemination and unauthorizeduse of their confidential personal and financial information.

Conventional commercial transaction models typically require a purchaserto establish an account with each merchant with which the purchaserwants to conduct a commercial transaction. Generally, the account isprotected and accessed via a login name and password, requiring apurchaser to manage multiple login and passwords and maintain whichlogin/password combination corresponds to which account. Some customersmay resort to storing their login/password combinations locally on theircomputer, or using the same login/password combination for all accounts.Both attempts to manage multiple accounts are vulnerable to theft,hacking, and/or other security breaches.

For example, a customer is at risk of having all of his/her accountsbreached should the single login/password combination be obtained byelectronic theft. In addition to the inherent security risks associatedwith conventional login/password paradigms, purchasers may find theaccount login procedure an awkward transaction experience. Inparticular, having to login to an account when a purchase is desiredmakes the transaction less convenient, as a purchaser must, in one wayor another, produce this information before a transaction can becompleted. Moreover, with third party transaction providers, thepurchaser is redirected from a merchant's website to the third partytransaction provider's website. This step is not intuitive and, at best,is cumbersome and confusing to the purchaser.

Applicant has identified and appreciated that delegating at least someof the transactional responsibilities handled by the purchaser andbrowser in conventional models to lower level systems (and away from thebrowser and end-user), may facilitate a simpler and more secure onlinecommercial transactions framework. In one embodiment, one or moretransactional tasks are handled by the operating system (or some othertrusted subsystem) at one or both of the end-user and merchant, whereinformation may be more securely safeguarded. By embedding one or moretasks in the operating system, users may be relieved of some of theburden of transferring transactional information, making the experiencemore intuitive and enhancing security. Moreover, the merchant may berelieved of maintaining purchaser information, handling of paymentinformation and/or processing the transaction.

Applicant has further appreciated that problems associated withvalidating the identity of the user may be mitigated by exploitingtechnologies more secure and convenient than the login/password model.In one embodiment, identity information about a purchaser is provided bya subscriber identity module (SIM) card which stores identityinformation about the end-user that can be issued programmatically. Inanother embodiment, identification information is provided by a smartcard embedded or otherwise coupled to a network device from which apurchaser conducts an online commercial transaction. Use of any ofvarious chip or card based identity means allows a purchaser to link hisor her identity with a particular device, such as a cellular phone or anetworked computer.

The term “programmatically” and/or “automatically” refers to actionsperformed substantially without manual or operator involvement. Inparticular, programmatic or automatic refers to actions initiated and/orperformed by one or more computer programs. For example, providingidentification information by requesting a user (e.g., purchaser) toprovide login and/or password information would not be consideredprogrammatic as the substance of the action is performed by the user.However, an action wherein a program issues identification information(e.g., a SIM number, network address hardware ID, etc.) withoutrequesting the user to input the information would be consideredprogrammatic. Note that such automatic operations may be implemented byeither software or hardware components.

Applicant has further appreciated that distributing varioustransactional elements of online commercial transactions over differentnetwork devices, facilitates more secure commercial transactions over anuntrusted network. In one embodiment, an identity provider and a paymentprovider, both separate and distinct network entities from the end-user,merchant and each other, provide verification support during acommercial transaction. The term “network entity” refers herein to anetwork presence and may be one or a combination of end-user/purchaser,identity provider, payment provider, merchant, etc. A network entity mayhave a presence on a network via one or multiple network nodes. Forexample, multiple networked devices may operate under the auspices of asingle network entity, such as an identity provider utilizing multipleservers to conduct online business, or an end-user connected to anetwork via a cellular phone and a personal computer. A network entitymay be a business such as a bank or retailer, or an individual such asan end-user.

In one embodiment, various elements of an online transaction aredistributed over separate and independent network entities. For example,the identity provider may provide identity validation in the form of anidentity token, which the merchant can use to verify the identity of thepurchaser. The identity token may include one or more identitycredentials of the end-user. The identity token may be issued based onthe identity information provided by the end-user/purchaser, forexample, the subscribe number from the SIM card, a network address(e.g., a Network Interface Card (NIC) identification, World Wide Name(WWN), etc.), login information, etc. Similarly, the payment providermay provide verification of the end-user's ability to pay in the form ofa payment token. In addition, the payment provider may handle paymenttransactions on behalf of the purchaser in satisfaction of the purchaseof goods and/or services from the merchant. The above describedframework allows, inter alia, a purchaser and merchant that arestrangers to conduct an online commercial transaction in an untrustednetwork environment in relative confidence, as discussed in furtherdetail in the various exemplary embodiments provided below.

For example, one embodiment provides for a three-way securecommunication between a merchant, consumer, and payment provider duringa commercial transaction for purchasing services and/or goods in eitheran online or retail environment. As will be discussed in greater detailbelow, payment tokens are passed from the payment provider to themerchant via the consumer. Such payment tokens offer proof of theconsumer's ability to pay for the service and/or goods by allowing themerchant to validate the authenticity of the token directly with thepayment provider. Although such payment tokens uniquely identify theauthorization of payment for the services and/or goods, sensitiveinformation about the billing account for the consumer is either notincluded within the token or otherwise encrypted so as to be invisibleto the merchant. Accordingly, the consumer's sensitive information isopaque to the merchant, thereby allowing the consumer to confidentlypurchase items from the merchant even when no trusted relationshipexists between them. Further, because the merchant can validate thepayment token directly with the payment provider, the merchant candeliver the items with confidence of the consumer's ability to pay forsuch services and/or goods without maintaining financial informationabout the consumer (e.g., credit card numbers, account information,etc.). In addition, because the payment provider can validate theauthenticity of the payment token as coming from the consumer, thepayment provider can confidently transfer funds to the merchant; thuscompleting the three-way secure commercial transaction.

As previously mentioned, other embodiments for the framework providedherein move portions of the transaction to more secure subsystems of acomputing device (e.g., the operating system). This advantageouslyallows for numerous capabilities including: an abstraction model forallowing legacy applications to provide in-band online commercialtransaction experience; additional types of fraud protection; billcapture and presentation for auditing, payment federation, and otherpayment or authentication purposes; service provider code execution foradditional security and merchant specific functionality; multilevelauthentication; and other features. For example, such abstraction modelallows legacy and other applications to provide a user with an onlinepurchase and payment capabilities as if such transaction occurs directlywithin the application, although portions of the commercial transactionare performed out-of-band. Examples, include catalog purchase (e.g.,Amazon, Sears, etc.), direct purchase of multimedia content from withinthe multimedia application, download software/games in trial mode andautomatically unlock them through in-band payment model, enable paymentfor subscription based services such as simple message service throughemail, etc.

Further, in another embodiment, the framework captures and presentselectronic bills in the above three-way secure (and other) commercialtransactions as a mechanism for additional authentication, auditing,payment federation, and other purposes will be described in greaterdetail below. Moreover, by moving the commercial transaction to moresecure portions of the subsystem, other embodiments allow a merchant torun specific code on a machine (e.g., additional user authentication,payment rules/mechanisms, user experience, etc.) with confidence thatsuch code will not be hacked or otherwise compromised. Of course, asdescribed in greater detail below, Applicant has further realized otheradvantageous features through the use of the abstraction model providedherein.

In another embodiment, Applicant also provides for an overall system andprotocol that uses a mobile module for secure communication andauthentication of identity and payment capabilities for a variety ofdifferent services. For example, a subscriber identity module (SIM) (orother similar mobile module) can be used to authenticate a user and/ordevice to a service or server in a multilevel validation environment. Insuch embodiment, the mobile module (and possibly even the user) isauthenticated over a network independent of the network mobileinfrastructure for the mobile module. Thus, the system validates thepossession of a mobile module through authentication of an activebilling account with the mobile infrastructure. This establishes asecure communication with a computing device connected to the mobilemodule and a service (e.g., a Web Services (WS)) using existing secureprotocols (e.g., WS-Authentication, WS-Security, and other similarprotocols). Such secure communication can also be used to authenticatethe user through other protocols and data exchanges between the mobilemodule and the mobile infrastructure—as described in greater detailbelow. Further, other embodiments provide for a protocol and statemachine that abstract the computing device (used in the communicationover the independent network) from the mobile infrastructure.Accordingly, the mobile module itself becomes a mobile terminal and thecomputing device becomes a peripheral device, thus complying withcurrent wireless standards such as 3GPP (3rd Generation PartnershipProject).

FIG. 1 illustrates a block diagram of a commercial transaction system100, comprising a plurality of network nodes including an end-user(purchaser) computer 110, a merchant computer 140, an identity providercomputer 120, and a payment provider computer 130. Each of the abovenodes may include one or more computing devices interconnected vianetwork 105. It should be appreciated that the end-user computer,merchant 140, identity provider 120 and payment provider 130 may beassociated with a network entity, such as an individual, company orbusiness. For example, end-user computer 110 typically is associatedwith an individual that employs the computer to access resources on thenetwork and merchant computer 140 may be associated with a corporationor business offering goods and/or services for sale. The one or morecomputing devices that form each mentioned component in commercialtransaction system 100 may operate as the point of entry, computingplatform and/or vehicle by which the associated network entitiescommunicate over the network.

Note that although embodiments provided herein may be described in anonline purchasing environment, embodiments can also be used in a directretail transaction. For example, the above and following description ofa commercial transaction can apply to a consumer purchasing products ina retail store, wherein payment, identity, authorization, and otherembodiments are used. Accordingly, the use of an online experience fordescribing embodiments herein is for illustrative purposes only and isnot meant to limit or otherwise narrow the scope of embodiment unlessotherwise explicitly claimed.

Also note that network 105 may be any type of network in any type ofconfiguration that interconnects and allows nodes connected to thenetwork to communicate. Nodes or devices may be connected to the networkvia copper (e.g., Category 5) cable, optical connections, wireless orany combination thereof. Information may be transferred using any lowlevel protocol such as Ethernet and/or any information protocol such asTCP/IP. The network 105 may have any number of devices connected to itand may be a trusted (e.g., intranet) or an untrusted network (e.g.,LAN/WAN, Internet, etc.), or a combination of both. The computersconnected to the network may be any type of device including, but notlimited to, one or any combination of a mobile phone, a desktopcomputer, a tablet personal computer, a server, workstation, etc.

FIG. 2 illustrates a diagram of a system and method for initiating andperforming identity verification in an online transaction, in accordancewith one embodiment of the invention, and FIG. 3 illustrates a diagramof a system and method for performing payment negotiation, verificationand/or certification in an online transaction, in accordance with oneembodiment of the invention. The methods may be used separately or incombination to perform an online transaction between anend-user/purchaser and a merchant. In the following description, unlessspecifically pointed out, no distinction is made between the networkentity and its associated networked devices. For example, “identityprovider” is used generically to describe the identity provider as anentity (e.g., a bank, government organization, agency, etc.) and as thecomputing devices that the entity utilizes to perform various networkfunctions, such as providing identity verification for an end-user, orotherwise operating on the entity's behalf.

An end-user computer 110 may place an order 242 with a merchant 140. Theorder 242 may be any indication that the end-user would like to purchaseone or more goods and/or services from the merchant 140. For example,the order 242 may result from end-user selecting a good or service via aweb browser displaying pages resident at the website of a merchant, ormay result from choosing an option from an application running locally,as described in further detail below. As an example of the firstinstance, the merchant 140 may provide a website to display or otherwiseoffer for sale goods and/or services that it provides, or may provide anonline catalog of merchandise. The order 242 may be any type ofindication that end-user would like to purchase one or more goods and/orservices from the merchant 140.

As an example of the second instance and as an alternative to selectingone or more goods and services from a merchant's website, order 242 mayoriginate from an application or other program local to the end-usercomputer 110. For example, an end user may create, produce or edit adocument via a word processing application, design a slide show using apresentation application and/or manipulate images or graphics for aposter or brochure using an imaging application. The application mayinclude an option under the print menu that allows the document to beprinted by a third party to, for example, take advantage of printingfeatures that may not be locally available, or to otherwise exploitprofessional printing services. When the option is selected, theapplication may send, via the network, order 242 to the merchant 140. Itshould be appreciated that order 242 may be any indication to purchaseany good and/or service, as the aspects of the invention are not limitedin this respect.

In response to order 242, merchant 140 may request that end-user 110provide an indication of the end-user's identity and/or verificationthat the end-user is indeed who he/she purports to be (step 205). Forexample, merchant 140 may not know anything about the source of order242 and may desire information about the identity of the end-user and/orassurance that the end-user is not spoofing his/her identity.Alternatively, the merchant 140 may send a notice or indication thatpayment is required for the service and demand that a payment token beprovided. To obtain a payment token, it may be necessary to firstestablish an identity via an identity token, as described in furtherdetail below. In either case, end-user 110 may respond to the request bythe merchant 140 by enlisting the services of identity provider 120(step 215).

To obtain an identity token, end-user 140 provides identity informationto identity provider 120. Identity information may include anyinformation that enables the identity provider 120 to distinguishbetween end-user utilizing end-user computer 110 and the various otherend-users to which identity provider may provide services. For example,the identity information may include a unique identifier associated withthe hardware of end-user computer 110. In one embodiment, the identityinformation is provided by a SIM card issuing an identifier unique tothe subscriber. Identity information may include providing a uniquehardware number of the network interface card (NIC) of the end-usercomputer 110, a world wide name (WWN) or other network address ofend-user computer 110 or any other means by which end-user computer 110may be identified, including (in some embodiments) an established loginname/password combination.

Identity provider 120 uses the identity information to locate identitycredentials associated with the end-user. For example, identity provider120 may include a database that stores identity information andcredentials on a plurality of end-users. The identity information may beused to index into the database to obtain the correct identitycredentials. The identity provider 120 may be any type of entity. Forexample, identity provider 120 may be a mobile phone company that usesthe subscriber number provided by the end-user's SIM card to locate theappropriate identification information. In one embodiment the subscribernumber is used to locate and obtain information provided by the end-userat the time of subscription to the cell-phone or other device exploitingSIM technology. The identity provider 120 may be a bank, a governmentagency (such as the registry of motor vehicles (RMV)), or any otherfacility that maintains identification information or credentialsassociated with end-users.

In response to the identity information provided by the end-user,identity provider 120 provides an identity token to end-user computer110 that provides identity authentication and/or credentials about theend-user (step 225). The identity token may be any type of electronicmessage that another network device can use to authenticate, verifyand/or determine an end-user's identity. For example, the identity tokenmay include identity credentials of the end-user. Identity credentialsmay include, but are not limited to, any one of or combination of name,birth date, address, telephone number, email address, etc.

The identity token may include an electronic signature from the identityprovider 120 certifying that the identity credentials are correct. Inthis way, a merchant and/or payment provider may rely on a disinterestedthird party (i.e., an identity provider), rather than therepresentations of an arbitrary end-user. The identity token may beencrypted before being transmitted over the network and decrypted whenreceived by the desired network device (e.g., merchant, paymentprovider, etc., as discussed in further detail below), to protectagainst eavesdroppers on the network. In other embodiments, the paymenttoken is merely a certification of the end-user's identity withoutaccompanying identity information.

The identity provider 120 may transmit the identity token to end-usercomputer 110 to forward to merchant 140 (step 235), and/or identityprovider 120 may transmit the identity token directly to the merchant140. Merchant 140 may then process the identity token to identifyend-user and/or to verify that end-user is who he/she purports to be.The identity token may be used to authenticate certain information aboutthe end-user that may affect the transaction. For example, the merchant140 may provide a service that requires the end-user to be of a certainage. Identity credentials transmitted with the identity token may beused to ensure that the end-user is of the proper age and meets thisrequirement. Merchant 140 may have discounts for particular end-usersthat are frequent purchasers, or who received a coupon, promotionaloffer, etc. The merchant 140 may index a database of end-users todetermine whether the end-user qualifies or should otherwise bespecially handled based on the provided identity credentials.

Optionally, the merchant 140 may request validation of the identitytoken by sending a request to the identity provider 120 (step 245). Therequest for validation of the identity token may include forwarding theidentity token from merchant 140 to identity provider 120. Uponreceiving the request for validation of the identity token, the identityprovider 120 may validate the identity token, and thereby determinewhether the identity token is authentic. The identity provider 120 maythen forward an indication of the validity of the identity token to themerchant 140 (step 255). Alternatively, the merchant 140 may simplyvalidate the identity token itself (step 265) (e.g., by assuming theidentity token is valid or otherwise processing the token). Optionally,a response may be returned from the merchant 140 to the end-usercomputer 110, where the response may include a message of whether theidentity token is valid, of any applicable discount or promotionaloffers, and/or any other type of message, as the invention is notlimited in this respect (step 265).

After the merchant 140 has processed the identity token and/or hasreceived a validation for the identity token from the identity provider120, the merchant 140 may request that the end-user provide verificationor validation of an ability to pay and/or provide an indication of howthe end-user would like to pay for the goods or services. The merchant140 may make the request via a payment token request (step 305 in FIG.3). In response to the payment token request, the end-user computer 110may enlist the services of a payment provider 130. Payment provider 130may be associated with a third party that maintains financial andpayment information about various end-users, such as a financialinstitution, or a third party broker that handles financial transactionsand payment procedures.

The end-user computer 110 may solicit a payment token from a paymentprovider 130 (step 315) by transmitting the identity token to paymentprovider 130. Alternatively, the end-user may request a payment token bylogging onto the payment provider 130 in a manner similar to thatdiscussed in connection with the identity provider 120 (i.e., byproviding an identifier such as a SIM subscriber number, NIC addressand/or using a login/password combination). It should be appreciatedthat the end-user may request a payment token in other ways, as theinvention is not limited in this respect. In addition, the end-user maysend information about the purchase, such as the price and nature of thepurchase so that the payment provider can verify that the end-user iscapable of paying. However, providing purchase information is notrequired, as it may not be necessary or it may be handled in subsequentsteps of the transaction.

Payment provider 130 processes the identity token (or other providedidentifier) to locate information about the end-user. For example, thepayment provider 130 may access a database of payment information basedon the identity credentials transmitted with the identity token. Paymentprovider 130 may determine what payment capabilities and options theidentified end-user has available. The payment provider 130 may thenverify that the end-user has the ability to pay, and in responsegenerate and transmit a payment token to the end-user computer 110 (step325). The payment token may indicate the end-user's ability to payand/or a certification that the payment provider 130 is willing tohandle the transaction on the end-user's behalf. The end-user computer110 may then forward the payment token to the merchant 140 (step 335).

The merchant 140 processes the payment token such that the merchant 140is satisfied that the end-user is able to pay for the goods or services(step 365). For example, the merchant 140 may ask the payment provider130 to validate the payment token (steps 345, 355) or may simplyvalidate it itself (step 365) (e.g., by assuming the payment token isvalid or otherwise processing the token). The merchant 140 may thenbegin the process of providing the goods and/or services to the enduser. Because the payment provider 130 may be a disinterested thirdparty, merchant 140 may treat the payment token essentially as paymentand may not have to wait until the transaction is fully processed.

When a merchant deals directly with the end-user in conventionaltransactional models, the merchant may have to ensure that the paymentinformation provided by the end-user is correct and sufficient. Forexample, a merchant may have to run a provided credit card numberthrough the credit card system to query whether the number is valid, thecard is valid, there are sufficient funds and/or the card is correctlyassociated with the identity provided by the end-user. If somethingdoesn't check out, the transaction may have to be canceled, terminatedor abandoned. Moreover, the termination of the transaction may happenafter the end-user perceives the transaction to be complete and is nolonger accessing the network and/or is no longer accessing themerchant's website, etc.

The merchant may then have to notify the end-user that there was aproblem with transaction and the end-user will have to go through thetransaction again to correct the problem (e.g., by correctly inputtingpayment information, specifying a different card with sufficient funds,etc.). In some instances, the end-user may not be notified and thecommercial transaction may never be completed.

In various embodiments discussed herein, because a payment token willnot be issued unless the end-user payment information is correct,sufficient funds are available, and/or the payment provider otherwisecertifies that it will pay on the end-user's behalf, the merchant canproceed with the transaction immediately. Any deficiencies in thetransaction may be identified in real-time and addressed so that allparties can be relatively certain that there expectations are being metwith respect to completion of the transaction.

In addition, because the payment provider may handle the financialtransaction (e.g., handling the credit card, transferring funds, etc.),the merchant may be relieved of establishing and maintaining theinfrastructure necessary to, for example, process credit card numbers orotherwise handle payment procedures and funds transfer. The paymenttoken, in some cases, operates as an assurance that the payment providerwill transmit the designated funds, for example, by wiring the money orenacting an electronic transfer of funds to the merchant. The paymenttoken may also be an assurance that the payment will be made bynon-electronic means such as a promise to issue to the merchant a checkor other negotiable instrument.

From the perspective of the merchant, the commercial transaction issubstantially risk free as the identity of the end-user and the paymentverification is handled by third parties and is therefore lesssusceptible to fraud, spoofing and even innocent mistakes in providingpersonal and financial information. Therefore, merchants may be morewilling to conduct online commercial transactions with unknown end-usersover an untrusted network. From the perspective of the end-user,personal and financial information resides with entities either thatalready maintain the information and/or that the end-user has anestablished relationship with. Confidential personal and financialend-user information need not be provided to the merchant, mitigatingthe vulnerabilities of having confidential information misused ormisappropriated. As a result, end-users may be more willing to conductcommercial transactions with unknown merchants without having to worryabout whether the merchant is trustworthy or not.

In some conventional commercial transaction models, identity informationand payment information are input by the user and processed by either athird party or the merchant. As discussed above, these models areawkward, inefficient and time consuming for the user. In addition,conventional models present numerous issues regarding security of anend-user's confidential information as well as making a merchantvulnerable to fraud and/or susceptible to failure to pay by an end-user.Applicant has appreciated that commercial transaction software installedon each of the computers employed in various commercial transactions maymitigate or eliminate concerns over security and fraud. In addition,many of the actions handled by the end-user and merchant in conventionalmodels may be performed by the commercial transactions software, makingthe transaction simpler and more intuitive to the end-user.

FIG. 8 illustrates an example of using some of the features describedabove for a three-way secure communication and various trust boundariesthat may be established during a commercial transaction. As will bedescribed in greater detail below, this model allows for single orsubscription payments, as well as payment federation such that a serviceor merchant can aggregate payment for smaller companies; thus enablingthe customer to pay a single bill. As shown, a distributed system 800 isconfigured to facilitate a commercial transaction between a consumer810, merchant 830, and a payment provider 805. A payment trust boundary815 divides the merchant 830 from the consumer 810/payment provider 805such that a trusted relationship exists between the payment provider 805and the consumer 810 or customer computing device (i.e., the consumerhas appropriately identified or authenticated itself to the paymentprovider using any of the available mechanisms as described herein).Accordingly, the consumer 810 can utilize this trusted relationship toauthorize payment to the merchant 830 for various types of payments andvarious types of services.

For example, assume that the merchant 830 requires reserve payment for aproduct (e.g., a custom item that requires prepayment like a car,computer, etc.), which the consumer 810 wishes to purchase. Prior torequesting payment authorization, however, the user of the consumer 810computing device may require appropriate authentication as describedherein. Once the user authenticates, the consumer 810 computing devicecan appropriately request payment from the payment provider 805 throughany various mechanisms as also described herein. For example, theconsumer 810 may provide the payment provider with billing or otherrequest information that is signed or otherwise encrypted by theconsumer's 810's computing system. This authenticates the request forvalidation of the account holder's (i.e., the consumer's) ability toappropriately pay (i.e., the user has a prepaid account, credit account,or other billing account such as a mobile subscription as describedbelow). If successful, a payment token is issued and the funds are thenreserved for guaranteeing payment. Such payment token is typically thensigned and/or otherwise encrypted by the payment provider (e.g., amobile web server as described herein) and passed to the consumer 810client. The consumer 810 passes the payment token back to the merchant830, which verifies the token against the payment provider, and ifsuccessful completes the order.

Once the item is ready for delivery (e.g., the custom item has beenbuilt), the merchant 830 can use the reserve payment token to requestpayment from the payment provider 805. Note that the amount of therequest for payment may be different than the amount reserved.Nevertheless, the payment provider 805 verifies and returns a paymentresponse to the merchant 830 and/or consumer 810. If approved themerchant 830 can ship (or otherwise provide) the order to the customer810 and be provided with payment thereof. If, on the other hand, thepayment is rejected or further user interaction is required, themerchant 830, payment provider 805, and/or consumer 810 can choose whatcourse of action to take. For example, if the amount requested by themerchant 830 does not match the funds reserved, the payment provider 805and/or merchant 830 may request authorization from the consumer 810 forthe new amount. Alternatively, the payment provider 805 may require userinput authorizing the transfer of funds regardless of any change inreserved and requested payment amounts. Of course, other actions andprocedure for completing the commercial transaction are alsocontemplated herein.

Note that although the above three-way secure payment mechanism was usedto purchase a reserve item, the single payment may also apply to otherservices and/or goods. For example, the single payment mechanism mayapply to a software program that is ready for immediate download.Alternatively, or in conjunction, the single payment may unlock variouslevels of a program that was downloaded (e.g., student version,professional version, or other separate functionality). In fact, as willbe appreciated the above single payment can be used for a variety ofdifferent types of purchases, some in a slightly modified payment form.

For example, suppose the consumer 810 wants to setup a subscription witha merchant 830 for continual service (e.g., a newspaper or magazinesubscription, movie subscription, gaming application, or otherpay-as-you go goods and/or services). Accordingly, the merchant 830 willchallenge the consumer 810 for a payment token, and thus the consumer810 client may interact with the user requesting authorization toproceed as described herein. Similar to above, the consumer 810 signs orotherwise encrypts the request for payment (e.g., using electronicbilling information as described herein below) and send such request tothe payment provider 805 (e.g., a mobile operator, credit card company,pre-paid or other type of third party service, etc.). This authenticatesthe request and verifies the account holder (i.e., the consumer orcustomer) has sufficient initial funds. If successful, a payment tokenis issued, signed and/or otherwise encrypted, and returned to theconsumer 810 client, which passes the payment token back to thesubscription merchant 830. The merchant 830 then verifies theauthentication of the token and completes the subscription setup.

Note that typically the payment token is stored at the merchant 830 andperiodically used when requesting subscription payment from the paymentprovider 805. Accordingly when processing subscription payment, themerchant 830 retrieves the payment token and sends it to the paymentprovider 805 for payment settlement. The payment provider 805 verifiesand returns a payment response to the merchant 830 and/or consumer 810.If an approved response is returned, the subscription merchant 830 willreceive payment during the next payment provider 805 account paymentrun. If the payment request is rejected, however, the payment provider805 and/or merchant 830 may respond appropriately. For example, themerchant 830 (or payment provider 805) may contact (e.g., via email) theuser or consumer 810 informing them of the outstanding payment. Theconsumer 810 can then perform a single payment as described above orsetup another subscription payment through either the same of differentpayment provider 805. Of course, the merchant 830, payment provider 805,and/or consumer 810 may have other rules or requirements for processingthese and other payment authorizations, as will be described in greaterdetail below.

As previously mentioned, other embodiments allow for federation of asingle consumer 810 payment to a plurality of business associates orsubsidiaries with a contractual arrangement. Often businessrelationships are complex and require distribution of payments forvarious services and/or goods provided within a particular businessmodel. For instance, when purchasing a trip from a travel agent 830, aconsumer 810 may be provided with a package deal including flightarrangements, hotel accommodations, transport services, etc. Themerchant 830, who typically contracts out many of such services and/orgoods, must then keep detailed accounting of such commercial transactionin order to make appropriate payments to its business associates. Inorder to alleviate the complexity of such accounting and other tasks,embodiments herein provide for an automatic payment federation tobusiness associates within a particular type of relationship on a pertransaction basis.

For example, a car rental service (e.g., business associate “A” 820) mayrequire payment from merchant 830 as part of a holiday package sale. Aninsurance company (e.g., business associate “B” 825) may charge themerchant 830 on a per transactional fee basis. Based upon the businessassociate trust boundary 835, payments are automatically federated toeach business associate (e.g., “A” 820 and “B” 825) when a singlepayment is made to the merchant 830. In other words, the consumer 810 orpayment provide 805 makes a single payment to the merchant 830; however,all subsidiaries with a business relationship according to the trustboundary for the business model 835 can be appropriately paid. Note thatsuch payment will typically be tied to the electronic billing statementas described in greater detail below. More specifically, various portionof an electronic bill for capture, presentation, and other purposes cancorrespond to what portion of payment should be federated to eachbusiness associate. Further, each of these portions may be signed and/orencrypted such that particular information about the payment is opaqueto the consumer 810, payment provider 805, or amongst the variousbusiness associates 820, 825 as defined by the various trust boundaries815, 825.

Note that although the above payment federation model was described withregards to a travel agent experience, other business relationships alsoexist that can use this embodiment. For example, companies who builditems with multiple components purchased through various vendors,product providers who buy materials for there product and make paymentsbased on a per item bases, payments for multimedia products who payroyalties based on each sale, or any other type of business model thatbundles or otherwise can calculate and make payments to businessassociates on a per item basis may also use embodiments describedherein. As such, the above use of the travel agent for describingvarious embodiments herein is for illustrative purposes only and is notmeant to limit or otherwise narrow embodiments described herein.

FIG. 4 illustrates a networked computer system for handling commercialtransactions, in accordance with one embodiment of the presentinvention. Networked computer system 400 may be similar to computersystem 100 illustrated in FIG. 1. However, in FIG. 4, each of computersin system 400 includes local installations of commercial transactionssoftware 485. In particular, end-user or consumer computer 410, identityprovider 420, payment provider 430 and merchant 440 include commercialtransactions software 485 a-485 d, respectively. The commercialtransactions software locally installed at each of the computers in thesystem may be the same, or may be customized for the particular computerin view of which role(s) the computer plays in the transaction (i.e.,whether the computer operates as an end-user node, a merchant node,identity provider node, payment provider node, etc., or some combinationof the above). In either case, each installation is configured tocommunicate with installations on other networked computers to performonline transactions. For example, each installation may be configured tocommunicate with installations on networked computers so as to performthe methods illustrated in FIG. 2 and/or FIG. 3.

In one embodiment, the local installation of the commercial transactionsoftware 485 a on identity provider 420 can create an identity tokenidentifying the end-user utilizing end-user computer 410. Furthermore,the commercial transaction software 485 a on identity provider 420 canforward the identity token to the end-user computer 410, the paymentprovider 430, the merchant 440, and/or any other computer, as theinvention is not limited in this respect. The local installation of thecommercial transaction software 485 b on the end-user computer 410 canissue identity information (so as to identify the end-user) in responseto an indication to conduct an online transaction between the end-userand a merchant. The local installation of the commercial transactionsoftware 485 c installed on payment provider 430 can receive theidentity token and generate a payment token verifying an ability of theend-user to pay (e.g., the payment token) for the online transaction.The local installation of the commercial transaction software 485 dinstalled on the merchant 440 can receive the verification of theability of the end-user to pay before proceeding with the onlinetransaction.

In one embodiment, each of the computers in system 400 operates using alocal installation of a same or similar operating system 495. Forexample, each of the computers in system 400 may operate using theMicrosoft Windows® operating system. Commercial transactions software485 may be a subsystem of the operating system. In this way, the variouscomputers employed in a commercial transaction communicate in aconsistent and known fashion. Since the commercial transactions softwareis communicating directly over the network and handling the validation,verification and security, the end-user and merchant need not knowanything about one another, and more importantly, may not need toestablish any trust relationship. In addition, because certain portionsof the transactions are handled by the operating system, much of thetransaction may be performed substantially invisible to the user,without requiring confusing and oftentimes awkward involvement by theend-user.

By having the commercial transactions software on each computer, variousencryption techniques may be used during transmission of informationfrom one computer to another. Moreover, further security features may beincluded such as identity tokens and/or payment tokens that are validfor a limited time period. For example, an identity token may include atime component that specifies a time after which any component receivingand processing the token should deem it invalid, and not honor the tokenas verification of identity and/or payment. The commercial transactionssoftware components may programmatically process any time limitsassociated with a token. This may prevent tokens obtained by “fishing”from being used inappropriately at a later date.

It should be appreciated that the commercial transaction software neednot be part of the operating system, but may be any program or group ofprograms local to computers involved in a commercial transaction thatcan communicate with one another over the network. For example, thecommercial transaction software may be an application developed by athird party that can be installed on the computers to operate on orindependent of the operating system installed on the computer. Theapplication may be configured to operate with any one or combination ofoperating systems so as to be available to computers or devices of awide range of capabilities and configurations, and not limited to anyparticular operating system, processor, instruction set, etc.

FIG. 5 illustrates a commercial transaction initiated by an end-userselecting one or more desired goods and/or services, wherein thetransactional components of the purchase are handled, at least in part,by a transaction software subsystem distributed as part of the operatingsystem of the various computers involved in one or more transactions. Anend-user connected to network 505 through end-user computer 510 may berunning an application 555. Application 555 may be a browser displayingthe website of a business that offers merchandise or services for sale.Application 555 may be an application that provides an option to engagein an online transaction, such as an imaging editing program that allowsusers to manipulate images.

The end-user may select one or more goods or services to purchase viaapplication 555. For example, the end-user may wish to have an editedimage professionally printed on photo quality paper. Application 555 mayinclude such an option under the print menu. The print option, whenselected, may generate a window or dialog box listing all of theavailable printing options, including services available over thenetwork. For example, the print option may list service providers 540 a,540 b and 540 c as options for providing the printing service. When theuser selects one of the service providers, an online commercialtransaction as described above may be initiated. In particular, theservice provider may request that the end-user provide an identitytoken. In response, application 555 (or an application embedded incommercial transactions software 585), may generate a dialog box orinterface listing available identity providers. For example, asdescribed in greater detail below, the dialog box may list identityproviders 520 a, 520 b and 520 c as possible identity providers that theuser may select to handle identification verification.

FIG. 9 illustrates the use of a trusted commercial subsystem and otherfeatures in a distribute system and in accordance with exampleembodiments. As shown, a local computing device 920 within distributedsystem 900 is configured to provide an online or local retailtransaction in accordance with embodiments described herein. Note thatalthough the trusted commercial transaction subsystem 965 is shown onlyas part of the local computing device 920, similar subsystems may alsoreside on other network entities. Further note that although variouscomponents or modules may be described herein as residing on anyparticular network entity, such components or modules may be distributedthroughout the computing system and reside on any number of networkentities (i.e., portions may exist on one or more network entities).Accordingly, the specific aesthetic layout and use of a particularmodule by a network device or entity is used herein for illustrativepurposes only and is not meant to limit or otherwise narrow the scope ofembodiments herein.

Regardless of the distribution and aesthetic layout of the computingsystem 900, as previously described there exists a trust boundary 906separating the trust relationship between the various components.Although the relationship may be divided up differently, in the presentexample the trusted relationship exists between the payment provider 990and the trusted commercial transaction subsystem 965. Thisadvantageously allows for many features that current commercial systemscannot provide. For example, the trust boundary 906 abstractsapplications 925 from the commercial transaction with the merchant.Accordingly, legacy and other applications 925 can provide an in-bandexperience to the end user 940, although much of the functionalityappears out-of-band. For instance, in the above example of allowing aprofessional image printing on photo quality paper, the selection withinthe pull down menu, the identity validation, payment options, and othercomponents for assisting the user in such service purchase appears aspart of the application 925. Accordingly, the application 925 whenreceiving input to purchase services and/or goods can make a purchasecall 930 into the trusted commercial transaction subsystem 965, which isthen used to generate dialog boxes, receive user 940 input 935, andotherwise automatically communicate with the merchant 905 and/or paymentprovider 990 as described herein.

In other words, the user 940 does not need to necessarily trust theapplication 925 or the merchant 905 in the commercial transaction. Instead, the trust is limited to the subsystem 965 of the presentframework, which reduces the degree or levels of trust needed toconfidently and securely perform a commercial transaction. That is, theaccount details 950 for the user 940, which include sensitiveinformation 955 that the user 950 is unwilling or uncomfortable topublicly share (e.g., credit card information, personal information,user names/passwords, etc.), are accessed via either direct user input935 to the subsystem 965 or from secure 960 account information store945. As such, applications 925, merchant 905, and other components areabstracted away from financial and other billing account details 955controlled by the subsystem 965 as described herein. This is verydifferent from current commercial transaction models described abovewhere applications 925 or merchants 905 maintain and control accountinformation. Accordingly, this and other embodiments described hereinadvantageously provide for additional layers of security during suchcommercial transactions. This is a much more directed trust relationshipin order to minimize the number of components or organizations that haveaccess to or touch the very sensitive financial data.

Also shown in FIG. 9, and similar to the three-way secure commercialtransaction described above, the trust boundary 906 also indicates asecure communication between the payment provider and the trustedcommercial transaction subsystem 965. Accordingly, the subsystem 965authenticates to the payment provider(s) 990 in any one of numerous waysdescribed herein, allowing for secure communication therewith. Similarto above, local computing device (which can be a handheld portabledevice as described below in a local retail transaction, a personalcomputer in an online transaction, or other similar device as describedherein) desires various services and/or goods offered by merchant(s)905. In this example, billing information 910 is presented to the localcomputing device 920 for authentication, auditing, and other purposes asused in example embodiments described herein. Such billing informationmay include, but is not limited to, cost of the merchandise and/orservices, detailed description of the commercial transaction, merchant905 specific information, federation payment information, type oftransaction (e.g., single payment, subscription, etc.), or other typesof billing information. The bill information 910 may also include otherinformation such as merchant constraints and payment options asdescribed in greater detail below.

In one embodiment, the bill information 910 is an electronic billconfigured to be machine readable, which provides for many advantageousabilities of the current commercial transaction system. For example, oneembodiment provides that the billing information 910 can be part of thepayment token request 980 (or otherwise delivered in anothercommunication to the payment provider 990) as previously described. Assuch, the bill information may be used by the payment provider 990 forpayment token validation 940. More specifically, the bill information910 provided from the consumer or local computing device 920 can becompared with the payment token 985 information provided from themerchant 905 in the payment token validation 904. Accordingly, if thebill information 910 for the payment token validation 904 matches thebill information 910 from the token request 980, the payment provider990 can be further assured of the authenticity of the payment token 985and the validity of the merchant.

Note that how the bill information 910 from the merchant is relayed tothe payment provider 990 (as well as other components herein) may vary.For example, the bill information 910 sent from the merchant 905 to thepayment provider 990 may be a copy of the bill information 910 sent tothe trusted commercial transaction subsystem 965 or client 920.Alternatively, or in conjunction, the bill information 910 may be asigned and/or encrypted version from the payment provider 990, routedvia the consumer or local computing device 920. In either case, thepayment provider can do the comparison previously described forauthentication of the payment token 985.

Further note that such billing information 910 as used by the paymentprovider 990 can also be used to give a more detailed description ofcharges associated with a bill that will subsequently be presented tothe user 940 for charges on the user's account. Because this can also bea machine readable bill 910, the local computing device 920 can match upthe bill information 910 with that previously received by the merchant905 for further authorization of payment to the merchant 905. In otherwords, if the bill information 910 within the bill from the paymentprovider 990 does not match any received from the merchant 905, then thecharges may be considered fraudulent.

In another embodiment, the merchant 905 can use the bill information 910for auditing, user and other authentication purposes, paymentfederation, etc. For example, the merchant can sign or otherwiseencrypted portions of the bill information 910. This allows for multipleadvantageous features in embodiments described herein. For example, thebill information 910 may be part of the payment token 985 received bythe payment provider via the local computing device 920. The merchant905 can check the validity of the billing information 910 forauthenticating that the payment token 985 came from the client 920 ortrusted commercial transaction subsystem 965. Similarly, the during thepayment token validation 904, the merchant 905 can use billinginformation 910 received from the payment provider 990 to validate orauthenticate the payment provider 990 and/or local computing device 920.In other words, because the bill information 910 is routed to thepayment provider via the subsystem 965 or consumer 920, billinginformation received from the payment provider that matches that sent tothe client 920 can authenticate both the client 920 and payment token985 from the payment provider 990.

Note that in another embodiment, as briefly described above, the billinformation 910 can also be used by the merchant for payment federation.In this embodiment, various portions of the bill information 910 may bemachine readable for determining what portions of funds from the paymentprovider 990 (upon successful payment authentication) should bedistributed to business associates as previously described. Note that inthis embodiment, typically portions of the bill information 910 will beencrypted or otherwise opaque to the user 940 (or consumer client 920),payment provider 990, or other components not part of a businessrelationship with the merchant 905. This also uniquely identifies thebusiness associate in the billing federation, and can be used therebyfor authentication purposes. More specifically, the various portions ofthe bill information 910 specific to a business associate can beencrypted using a key specific such business associate, thus the billinginformation may only be seen by the merchant 905 and the specificbusiness associate. In other embodiments, however, the portions of thebill for payment distribution or federation are only signed by themerchant 905 to make then opaque to other components in the system 900.

Of course, as will be recognized, other uses of the billing information910 can be used for various purposes. For example, the billinginformation 910 can also be used for auditing purposes, productdistribution reconciliation, or any other well known business and otherpurposes. Accordingly, the above use of the bill information 910 forauthorization, identification, payment federation, or any other purposeis used for illustrative purposes only and is not meant to limit orotherwise narrow the scope of embodiments unless otherwise explicitlyclaimed.

Note that the trust boundary 906 and the subsystem 965 also have otheradvantageous features in other embodiments described herein. Forexample, as shown in FIG. 9, payment provider code 970 within thesubsystem 965 allows for securely running code specific to one or morepayment providers 990. Such code can be used for further authorizationspecific to the payment provider, e.g., biometric, radio frequencyidentification (RFID), user name/password, or any numerous additionalauthentication techniques. In other words, due to the trustedrelationship that the payment provider 990 has with the subsystem 965,the payment provider can run trusted code for its specific businesspurpose.

The use of such code 970 also allows for a more integrated in-band userexperience that can be controlled by the payment provider 990 or anyother component that has a trusted relationship with the subsystem 970.For example, although not shown, a trusted relationship may existbetween some merchants 905 and the subsystem 965 for allowing trustedcode thereof to be run by the subsystem 965. As such, the merchant 905,payment provider 990, or any other component involved in the commercialtransaction, may provide an integrated user experience that appears asif ran from within the application 925 (legacy or otherwise); however,many of the events occur out-of-band. For instance, in the above exampleof a photo quality print of an image by a professional service, thedialog boxes, payment options, or any other number of features presentedto the user or application functionality (e.g., in response to userinput) may be controlled by the code 970 specifically provided by thevarious trusted network entities (e.g., the payment provider 990, themerchant 905, etc.). Accordingly, as will be described in greater detailbelow, this code can also be used when evaluating payment options andother constraints from the merchant 905 and/or payment provider 990.

As mentioned above, in one embodiment, the selected service provider ormerchant transmits any requirements to the identity provider with therequest for identity verification. For example, service provider may beselling goods or services that require a minimum age or is restricted toa certain geographical location. Accordingly, the listing of identityproviders may be limited to those that can provide identity credentialsthat satisfy the requirements of the service provider. For example, thelist of identity providers may be restricted to those that can provideage verification or current address information, such as the RMV.

Likewise, a dialog box may be generated listing options for paymentproviders. For example, the dialog box may list payment providers 530 a,530 b and 530 c, which may include a credit card company, a bankoffering electronic debit services, or a private third party offeringfinancial services, respectively. As with the identity request, theselected service provider may include any payment requirementsassociated with the purchase. For example, the service provider may onlyaccept a certain type of credit card. The payment requirements may thenbe reflected in the available payment providers listed or enabled in thepayment provider selection dialog box. After a payment provider isselected, payment certification may proceed and the transaction may becompleted.

Note that other embodiments also provide for comparison of merchantconstraints (e.g., available payment options, age restrictions, etc.)with consumer rules for determining various actions that may be taken.FIG. 10 illustrates such an embodiment, wherein a distributed system1000 is configured to programmatically determine actions based on suchthings as merchant constraints 1010 and/or consumer rules 1035. Forinstance, merchant 1020 can define within the merchant constraints 1010payment providers 1005 or types of payment acceptable for purchasingservices and/or goods thereof. Decision module may then present suchconstraints to the user, e.g., in a user interface requesting user input1040 for choosing one or more of the available payment options. Based onthe user input 1040, the appropriate payment provider 1005 may becontacted for proper funding of the services and/or goods.

In another embodiment, consumer rules 1035 can also be used in additionto, or in place of, the merchant constraints 1010. For example, consumerrules 1035 may indicate that only certain types of payments can be madefor certain types of merchants 1020. More specifically, the consumerrules 1035 may indicate that if a merchant 1020 is not registered orotherwise trusted, that only payments that can be reversed may be usedfor purchased made from the merchant 1020.

Of course, as described above, other merchant rules 1010 and consumerconstraints 1035 can be used by decision module 1030 when determiningactions to take in a commercial transaction. In fact, the merchantconstraints 1010 and consumer rules 1035 may be compared forcompatibility and other purposes. For example, the available paymentoptions from the merchant 1020 can be compared to payment providers 1005available or allowable by the consumer when presenting the user with aselection of payment providers 1005. Of course, the payment selectionmay also occur automatically based on such things as a default setting,provider ratings or preferences, or any other number of option settings.If fact, any number of actions may occur based on the implementation ofthe various merchant 1010 and/or consumer 1035 rules. For example, ifthe rules (merchant 1010 or consumer 1035) fail or are otherwiseviolated, additional input from the merchant 1020 or user 1040 (eitherautomatically based on additional rules or settings) may be needed toresolve conflicts or other discrepancies. Accordingly, any particularaction taken when implement the constraints and/or rules defined areused herein for illustrative purposes only and are not meant to limit orotherwise narrow embodiments provided herein.

Further note that, as described above, the merchant constraints 1010 maybe included within the billing information or provided separately to theconsumer. Also note that the comparison of various rules and actionstaken thereby may all occur under the covers, i.e., without theknowledge of the user and/or other system components. In addition, notethat the present system is not limited to just constraints or rulesdefined by either the consumer or the merchant. For example, the paymentprovider may also define various restrictions that can also beconsidered in conjunction or instead of the consumer and/or merchantrules. Accordingly, the above use of merchant and consumer constraintsfor determining various actions (such as payment provider options) isused herein for illustrative purposes only and is not meant to limit orotherwise narrow embodiments herein described unless otherwiseexplicitly claimed.

In conventional online transactions, it may be difficult for both theend-user and/or the service provider to know for certain when atransaction is complete and whether the goods or services have beensuccessfully delivered. For example, an end-user may select a softwarepackage for download over the network, or an end-user may purchasesongs, movies or other electronic media. Sometimes a network connectionmay be disrupted before the download can be completed. Under suchcircumstances, the end-user may be tempted to select the merchandiseagain, but may be hesitant because the end-user does not know whether heor she will be double charged for the purchase. Likewise, the serviceprovider may not know if a download was completed successfully and maydouble charge when a user attempts to remedy the disruption by selectingthe merchandise again.

Applicant has appreciated that providing logging or auditingcapabilities in the commercial transactions software may eliminate someof the uncertainties with respect to electronic downloads. For example,final execution of the payment option may depend on a signal from theauditing feature that the download is complete. That way, if a downloadis interrupted, the end-user can be certain that the selected paymentoption did not go through. For example, commercial transactions software585 from FIG. 5 (or other subsystems or network entity components asdescribed herein) may include a logging feature that records all of thevarious steps of the commercial transactions conducted by the machine.The logging information may be used as proof of purchase or to otherwisememorialize transactions. In addition, commercial transactions software585 may include monitoring capabilities for electronic downloads, whichsends a verification of a successful download, only after which finalpayment will be made. By making payment contingent on a signal that thetransfer of goods or services was completed successfully, issues ofdouble billing may be addressed and substantially eliminated.

Software has been developed by companies to handle a wide variety oftasks including familiar word and document processing, spreadsheets,imaging editing, to more specialized tasks such as video editing,computer graphics software, web-content development applications,portfolio management software, etc. However, to own software thathandles each task that an end-user may want to perform may beprohibitively expensive. Software packages can cost anywhere fromhundreds to thousands to tens and even hundreds of thousands of dollarsto obtain a single license. Moreover, an end-user may need the servicesof a particular application only occasionally or sporadically, such thatthe cost of purchasing the application may not be justified.

Applicant has appreciated the benefits of enabling an end-user toutilize software in a pay-as-you-go environment. In particular, anend-user may be charged only for the amount of time spent using theapplication, rather than paying the retail price for the software (wheremany of the features and/or the application would go largely unused).FIG. 6 illustrates a networked computer system having a commercialtransaction framework that allows an end-user to pay for the amount oftime spent using the application. Networked computer system 600 includesa network 605 interconnecting end-user node 610 to a plurality ofidentity providers 620, a plurality of payment providers 630, andplurality of service providers 640.

End-user node 610 may be a computer running on an operating system 695.Installed on the end-user computer may be a plurality of softwareapplications 655. The software applications may have come bundled withthe computer at purchase, may have been downloaded freely over anetwork, or otherwise distributed (often for free or for a nominalcharge, or for registering with the vendor) by the seller of theapplication. Application 655 may be any type of application and anynumber of applications may be installed on the computer. Serviceproviders 640 may be associated with one or more applications installedon end-user computer 610. For example, service provider 640 a may be oneor more computers owned by the developer and seller of application 655a. Similarly, service providers 640 b and 640 c may be associated withapplications 655 b and 655 c, respectively.

In the pay-as-you-go model, the service provided by the serviceproviders is a license to use the associated applications installed onthe computer. For example, when software (e.g., applications 655) isfreely distributed, it may be initially disabled so that users cannotrun the application without first obtaining a license from the seller ofthe application. The license may be obtained by initiating a commercialtransaction with one or more of the service providers 640. For example,application 655 a may be a desktop publishing application that anend-user would like to use for a couple hours to design a card orbrochure. When the end-user opens application 655 a, the end-user isnotified that the end-user needs to purchase a license to use theapplication. For example, a dialogue box may appear listing thecharacteristics and prices of the various for-use licensingcapabilities.

A license may be for a specified amount of time, for example, an hour ora day. The license may expire once the application has been closed down,or the license could remain active until the term has expired. Thelicense could be based on operations or tasks that allow an end-user tocomplete one or more jobs or employ one or more desired features.Additional features to be used may increase the cost of the license. Itshould be appreciated that a license having any desired terms may benegotiated, as the aspects of the invention are not limited in thisrespect.

Once the end-user has selected a license option, the end-user may beinstructed to select an identity provider and/or payment provider, orone or the other may be selected by default to initiate an onlinetransaction. The transaction may be handled by commercial transactionsoftware 685 substantially as described in any of the foregoing orfollowing embodiments. When service provider receives a payment tokenfrom one of the payment providers 620, the service provider may transmita license according to the terms agreed upon at the initiation of thetransaction.

The received license may be processed by generic license service 690 sothat the appropriate accessibility to the application may be invoked.The generic license service may then issue an enable key to application655 so that the user may run the software and utilize its functionalityaccording to the license. The enable key may include any information theapplication may need to provide the necessary services for the termindicated in the license. The enable key may include a password providedby the service provider such that the application knows that the licenseis valid and/or may simply rely on the representation from genericlicense service 690 that a valid license has been obtained. Once theapplication is operating, metering engine 694 may be notified to keeptrack of time and to indicate to the application when the license hasexpired. Alternatively, the application may be programmed toperiodically query the metering engine and then disable itself when thelicense has expired. Moreover, by querying the metering engine, theapplication may give periodic warnings or updates to the user about theamount of time remaining in the purchased license, should the licenseinclude a term.

When the end-user is finished he may choose to have the completedproduct professionally printed and select a print option that initiatesanother online transaction such as the transaction described inconnection with FIG. 5. The pay-as-you-go license may provide users withmuch more flexibility and give them access to software that they wouldnot have had prior access to due to the cost of buying the softwarepackage with a lifetime license. In addition, software vendors cancapitalize on revenue from user's who were unwilling to pay full retailprice, but willing to pay for limited use and/or limited functionality.

Software piracy impacts profits across the entire software industry.User's of unlicensed software cost businesses relatively substantialamounts each year. Once a software product has been purchased, theseller has little control over where and to how many computers thesoftware is installed. Illegally providing software for download overthe Internet provides an even more pervasive method to distribute andobtain software that the end-user has not paid for. Applicant hasappreciated that providing a relatively secure and simple commercialtransactions framework with a pay as you go license scheme, for example,the framework described in the embodiment illustrated in FIG. 6, maymitigate or eliminate the piracy problems. Since the software isdistributed freely by the seller, end-users can appropriate the softwareanyhow they see fit. Since the software is enabled only through payingfor a term license or task license, end-users are substantially limitedin their ability to misuse the software.

As previously described, embodiments herein allow for authentication foridentity and/or payment purposes using a mobile module (e.g., asubscriber identity module (SIM)) tied to a particular billing accountof a mobile infrastructure or operating system. Unlike typical standardsfor mobile communications (e.g., Global Systems for Mobilecommunications (GSM), 3rd Generation Partnership Project, and othersimilar protocols), which occurs via a trusted radio network,authentication in accordance with embodiments herein takes place over anindependent untrusted data network (e.g., the Internet). As a result,embodiments herein address many of the additional security concernsimposed by the use of such mobile modules (SIMs) in a Web Services andother independent network protocol environments. Such security concernsinclude among other things: determining a trusted network endpoint forthe authentication of a server; authentication of a client to a mobilemodule or SIM device; authentication of a user to the SIM device;authentication of the SIM and authentication server; establishment of asecure network connection between the mobile module and networkauthentication server; and authentication of the user to the networkauthentication server.

Moreover, in order to comply with GSM, 3GPP, and other standards,additional requirements are placed on the terminal equipment, which willinteract with the mobile module or SIM device. More specifically, theGSM, 3GPP, and other similar standards require that the SIM restrictaccess to certain types of information, including encryption keys, tothe mobile terminal. In order to satisfy these requirements, embodimentsherein provide an abstraction security profile that delegates processingand decoding of certain messages and security to the SIM device itself.For example, as shown in FIG. 11, a firewall 1090 defines a statemachine and protocol messages for abstracting a SIM 1085 from a hostdevice 1075 when communicating over an independent network 1060. Morespecifically, the firewall 1090 uses a formal state machine that limitsor restricts the number and/or sequence of commands sent from a readdriver within the host 1075 to the SIM 1085 itself. Accordingly, the SIMdevice 1080 (e.g., a cellular phone, SIM interface, etc.—note that“mobile module” represents a generic term for a “SIM”, but is usedherein interchangeably unless otherwise specifically claimed) becomesthe mobile terminal and the host device 1075 becomes a peripheral thatcomplies with the communication protocol 1055 for the mobile network1050. The following describes in greater detail some of the statemachines and protocols used to address some of the additional securityrequirements and concerns outlined above.

Embodiments herein define a security profile for authentication over theuntrusted independent network (i.e., a network independent of a radionetwork corresponding to the mobile module's infrastructure or operatorsystem) in terms of various security levels that a given security tokenmay represent. These include, but are not limited to, device securitylevel, network security level, user security level, and service securitylevel. At each level are different requirements and procedures forobtaining a security token. Accordingly, as described in greater detailbelow, each security level represents a differing level ofauthentication in the security model and each has certain requirementsand/or assurances. Further, it should be noted that each security levelmay or may not be independent of the others. For example, it may not benecessary to establish a device security level before a network or usersecurity level can be achieved; however, for proper assurances suchhierarchical procedure may be desirable.

A device security level indicates physical possession of a mobilemodule, e.g., a SIM device such as a cellular phone. A device token(i.e., a SIM security token with a device security level) is typicallyissued locally by the mobile module or SIM device upon properauthentication by a user thereto. Such requirements for authenticating auser to the mobile module are normally set by the mobile infrastructureor mobile operator. Further, device authentication is usually enforcedby the SIM device, however, other embodiments may provide for the use ofother components in the authentication process. For example, the SIM orother device may require a password before the mobile module or otherdevice will issue a device token. Of course, other forms of credentialsfor authentication on the device level are also contemplated herein.

In one embodiment, a SIM device requires the client or host computer toauthenticate or identify itself to the mobile module before a devicesecurity token will issue. Further, the lifetime of a device token istypically controlled by the mobile module or SIM device using policy setby the mobile infrastructure. In one embodiment, the lifetime or otherrequirements set by the mobile operator may be dynamically configuredthrough the independent and/or radio network. If the device token doesnot have lifetime or other restrictions, typically the SIM does notrequire the user to re-authenticate to the mobile module more than once.

The network security level indicates an authenticated connection betweenthe mobile module or SIM and the mobile infrastructure or network overthe untrusted independent network. The network security level can beestablished without user presence or user interaction assuming anunlocked SIM device is accessible by the client or host computer.Typically, the network security level is a single factor authentication,which asserts proof of possession of the SIM device to the mobileinfrastructure or operator. Typically, the mobile infrastructure willissue a network security token via an authentication server and througha challenge response type mechanism before issuing a network securitytoken to a client or host computing device. This network security leveltoken can then be used in subsequent authentication phases and providestransport level security to encrypt and/or sign further interactionsbetween a client and an authentication server and/or mobileinfrastructure.

FIG. 7A illustrates an independent network 700 configured to issue anetwork level security token for establishing a transport level securecommunication between client and an authentication server. Typically,the client or host computing device 710 (which may be a personalcomputer, mobile phone, or other portable or non-mobile computingdevice) initiates the authentication request by sending a networksecurity token request 725 to the mobile infrastructure 720 via theauthentication/trusted server 715 (note, however, that the request mayalso be initiated by another device such as the SIM 705 itself).Usually, the request 725 will be unsigned when received by theauthentication server 715, which can then sign and/or encrypt therequest prior to sending to the mobile infrastructure 720 for validatingthat the request comes from the authentication server 715. The trustedserver 715 can then query the mobile infrastructure 720 or mobileoperator for a challenge 730, which will then be sent to the mobilemodule 705. The mobile module 705 uses a secret 740 shared between itand the mobile infrastructure 720 for generating a challenge response735, which is then forwarded to the client 710—note that typically thesecret will be SIM 705 specific and set by the mobile operator 720.

The client 710 will use the challenge response 735 to generate a requestsecurity token response, which may also include the SIM identity and thechallenge 730 for authentication purposes. Typically, the client willrequest that the mobile module 705 sign and/or encrypt the requestsecurity token response with the device's 705 shared secret 740 or otherkey such as the SIM's device token—although this may or may not benecessary. The request security token response and the challengeresponse 735 therein can be validated using, e.g., the shared secret740. Note, as previously mentioned, that the request security tokenresponse may or may not be signed and/or encrypted by the same key usedto generate the challenge response 735. In any event, if the mobileinfrastructure 720 validates the challenge response 735 (i.e., thechallenge response is valid and the mobile module has an active billingaccount), the mobile infrastructure 720 and/or authentication server 715can respond by generating a message that contains a network securitytoken 745 with encrypted session key(s), which are signed and/orencrypted using the shared secret 740. The message can further be signedusing either the authentication server's 715's own security token (e.g.,X.509 cert, Kerberos cert, etc.) or using the mobile infrastructure's720's security token. The client 710 can then verify the signed messageand pass the encrypted network session key(s) to the SIM 705 fordecryption. Using the shared secret 740, the mobile module 705 can thenreturn the un-encrypted session key(s) 750 to the client 710.

Note that in the above issuance of the network security token 745, themobile module 705 typically needs an active billing account in goodstanding on the mobile infrastructure 720. Accordingly, uponverification of the challenge response 735 and such active billingaccount information, a trust may be established between the SIM 705 andmobile infrastructure 720 creating a virtual secure channel. The sessionkey(s) 750 are then delegated or passed from the mobile module 705 tothe software platform or stack of the host computing device 710 and fromthe mobile operator 720 to the authentication server 715 (if necessary).Note the physical proximity of the mobile module 705 with the hostcomputing device 710 (which may be connected thereto via USB port,Bluetooth, or other wireless or wired connection) and the trustedrelationship between the mobile infrastructure 720 and theauthentication server 715. These session key(s) 750 are then used by theclient 710 and trusted server 715 for establishing a securecommunication 755.

Note that there may be a second mode of operation for authenticating themobile module 705, which may be used by the mobile infrastructure 720.In this case, the client host 710 may request that the SIM 705 generateand sign its own challenge (typically in the form of a Nonce). Theclient 710 can then attach the information as part of the device tokenwhen request the network security token 725 from the trusted server 715or mobile infrastructure 720. If the mobile operator 720 can verify thatthe device token contains a valid challenge-response 735, it maydirectly issue a network token 745 back to the client 710 for decryptionof session key(s) as described above.

As will be described in greater detail below, typically this networklevel security token 745 is required for allowing a client access to anauthenticated service token, which can be used to request servicesand/or goods from third party services. Note also that in order toobtain the network token, the above presumes that the client or hostcomputer device 710 has successfully determined the network endpoint forthe authentication server 715 and/or mobile infrastructure 720.Additionally, it presumes that the client 710 and the user (not shown)have already authenticated to the SIM device 705. As described above,the network security level token 745 is used in subsequentauthentication phases and provides transport level security to encryptand sign further interactions between the client 710 and the trustedserver 715. The lifetime of the network token 745 (and other tokens) iscontrolled by the authentication server 715 or mobile operator 720.Because the network token 745 servers as a session context between theSIM device 705 and the mobile infrastructure 720, the lifetime may belimited to hours or days, number of bytes passed, and/or may only bevalid if the mobile module 705 is properly connected to the client 710.

As previously mentioned, a user security level indicates a user hasauthenticated to the network (the trusted server 715, mobileinfrastructure 720, or other service) usually by providing informationstored outside the SIM 705 or host computing device 710. Accordingly,the user security level in conjunction with the network security levelestablishes a multifactor authentication based on proof of possession ofthe SIM 705 and some outside knowledge (e.g., a user name/password).Typically, the trusted server 715 or the mobile infrastructure 720 arethe only components to issue a user level security, however, in someinstances a third party service may also issue such user tokens.Accordingly, the mobile infrastructure 720 (or other service as the casemay be) will verify a user through a challenge response mechanism beforeissuing a user security level token back to client 710. Note that theuser security token is used by the client to sign and/or encryptrequests for service tokens as described below. It may not berecommended for the client to send a user security token to any serviceother than the trusted server (since typically no other service will beable to verify/use it). As with the above network token 745, the usertoken may have a limited lifetime controlled by the mobile operator 720,and may be limited by time duration, the number of bytes passed, and/orby the existence of the connection between the mobile module 705 and theclient 710.

FIG. 7B illustrates an independent network 700 configured to issue auser level security token for establishing a multilevel securecommunication between client 710 and an authentication server 715. Theuser network authentication phase allows the mobile operator 720 (orother server) to verify that a known person is in possession of a knowndevice 705. Effectively the user to network phase is a two factorauthentication phase and prevents the network from distributed denial ofservice attacks. In addition, it protects the user by preventing astolen SIM device 705 from being inappropriately used.

The host computing device 710 may issue a request for user token 765,which is sent to the mobile infrastructure 720 via the trusted server715. Usually, the request 765 will be unsigned when received by theauthentication/trusted server 715, which can then sign and/or encryptthe request prior to sending to the mobile infrastructure 720 forvalidating that the request comes from the authentication server 715.The trusted server 715 can then query the mobile infrastructure 720 ormobile operator for a challenge 770, which will then be sent to themobile module 705. Note that the challenge 770 may be generated using adifferent algorithm than the challenge 730 used for authenticating thedevice 705 to the network. The client 710 will extract the challenge 770from the token message and pass it to the mobile module 705, indicatingthat this is a user authentication. Accordingly, the SIM 705 willrequest user credential(s) 775 from the client 710. The host computer710 will then query the user 760 for user input 780, and return it tothe mobile module 705. The SIM 705 or client 710 may optionally decidethat the user input 780 or credential(s) should be encrypted with thenetwork security key (i.e., the session key(s) 750 previously obtained.

Using the user input 780, the mobile module 705 will generate achallenge response 785 and return it to the client 710, which willgenerate and send a request security token response that includes, e.g.,a SIM identifier, the challenge 770, and the challenge response 785.Typically, the client 710 will request that the mobile module 705 signand/or encrypt the request security token response with the networksecurity token 745, the shared secret key 740, or a SIM 705 specifickey. Similar to above, the request security token response and thechallenge response 785 therein can be validated using, e.g., the sharedsecret 740, or other mobile module 705 specific key. Note, as previouslymentioned, that the request security token response may or may not besigned and/or encrypted by the same key used to generate the challengeresponse 785. In any event, if the mobile infrastructure 720 validatesthe challenge response 785 (i.e., the user credentials provided areproper), the mobile infrastructure 720 and/or authentication server 715can respond by generating a message that contains a user security token795 with encrypted user key(s), which are signed and/or encrypted usingthe shared secret 740 or other device 705 specific key. The message canfurther be signed using either the authentication server's 715's ownsecurity token (e.g., X.509 cert, Kerberos cert, etc.) or using themobile infrastructure's 720's security token. The client 710 can thenverify the signed message and pass the encrypted user session key(s) tothe SIM 705 for decryption. Using the shared secret 740 (or other key asthe case may be), the mobile module 705 can then return the un-encrypteduser key(s) 790 to the client 710; thus authenticating the user to thenetwork 792.

The user to service authentication phase provides a mechanism for themobile network operator 720 to provide authentication on behalf of thirdparty services. Similar to the user to network security level, the userto service phase is a multifactor authentication phase and prevents thenetwork from issuing service tokens without a user 760 having beenpresent during at least one phase of authentication. There are typicallytwo modes of operation of the authentication server 715 regarding howservice tokens are issued. First, if the user 760 has previouslyacquired a user token, the trusted server 715 may consider the user 760to be authenticated and automatically issue a service token (providedthat the request for service token is appropriately signed with the usertoken 790, 795. If, on the other hand, the mobile infrastructure 720 hasnot issued a user token 790, 795, the user 760 will be required toauthenticate in a manner similar to that outlined above for requesting auser token 795, 790.

FIG. 7C illustrates how the various network entities communicate overthe independent network 700 when establishing secure communicationbetween a client 710 and third party server 728. As mentioned above, themobile device 705 and user 760 can authenticate to the mobile operatorsystem 720 as previously described. Accordingly, a secure communicationexists between the authentication server 715 and the client 710 uponproper validation of a billing account for the mobile device 705 andauthentication of possession thereof by the user 760. The trusted server715 (or mobile infrastructure 720 as the case may be) can then issueservice tokens 724 for various services when, e.g., the client 710wishes to purchase services and/or goods from a third party service 728.Accordingly, the client 710 can issue a service token 726 to the thirdparty server, which then validates the token 722 through theauthentication server 715. Note that the third party server 728 may ormay not require additional authentication and can use various mechanismsas previously described for performing such validation. Also note thatthe use of the service token 726 not only establishes a securecommunication between the client 710 and third party server 728, but mayalso indicate the user's 760's ability to pay for one or more servicesand/or goods in a manner similar to that previously described.

Note that typically up until the service token is issued to the client710, the security tokens issued are of no value to any other serviceother than the authentication server 715. The reason is that thesecurity hierarchy can prevent any outside party from properly decodinga device token, a network token, or even a user token, as they allderive from the root or shared key 740 known only to the SIM device 705and the mobile infrastructure 720. It is typically after theauthentication server 715 issues a service token 724 that an arbitrarythird party 728 web service can make use of a security token 724. Alsonote that the above security tokens and messages (e.g., challenges,challenge responses, etc.) may take on various formats or schemas. Forexample, the tokens and/or messages may be XML, binary, or other similarencoding format, which can be issued by the mobile operator 720 who mayor may not wish to expose certain elements of the network to SIMcommunications to intermediate parties.

The above use of a portable hardware device 705 for authentication,identity, and/or payment validation can be used for purchasing online orlocal retail service and/or goods (e.g., online newspaper, music,software application, or other goods and service) or for an allowingaccess to an application running on the local PC or client 710 (e.g.,Word®, Adobe Photoshop, Print program, pay-as-you go software, etc.).Accordingly, the above embodiments are especially advantageous forunlocking freely distributed protected software or content (e.g., music,videos, games, etc.) on a plurality of hosting devices 710. In otherwords, a license now becomes tied to the portable mobile device 705,which can be authenticated as described above allowing for a portabledigital identity not tied to a limited set of computing devices. As sucha user 760 goes to a friend's house and does not have to bring all ofhis/her programs or other protected content; it's all accessible andauthenticated via the portable device 705.

As should be appreciated from the foregoing, there are numerous aspectsof the present invention described herein that can be used independentlyof one another, including the aspects that relate to identity tokens,payment tokens, selecting one of a number of identity providers,selecting one of a number of payment providers, and the presence ofcommercial transaction software on an end-user system, a serviceprovider system, an identity provider system, and a payment providersystem. It should also be appreciated that in some embodiments, all ofthe above-described features can be used together, or any combination orsubset of the features described above can be employed together in aparticular implementation, as the aspects of the present invention arenot limited in this respect.

The above-described embodiments of the present invention can beimplemented in any of numerous ways. For example, the embodiments may beimplemented using hardware, software or a combination thereof. Whenimplemented in software, the software code can be executed on anysuitable processor or collection of processors, whether provided in asingle computer or distributed among multiple computers. It should beappreciated that any component or collection of components that performthe functions described above can be generically considered as one ormore controllers that control the above-discussed functions. The one ormore controllers can be implemented in numerous ways, such as withdedicated hardware, or with general purpose hardware (e.g., one or moreprocessors) that is programmed using microcode or software to performthe functions recited above.

It should be appreciated that the various methods outlined herein may becoded as software that is executable on one or more processors thatemploy any one of a variety of operating systems or platforms.Additionally, such software may be written using any of a number ofsuitable programming languages and/or conventional programming orscripting tools, and also may be compiled as executable machine languagecode. In this respect, it should be appreciated that one embodiment ofthe invention is directed to a computer-readable medium or multiplecomputer-readable media (e.g., a computer memory, one or more floppydisks, compact disks, optical disks, magnetic tapes, etc.) encoded withone or more programs that, when executed, on one or more computers orother processors, perform methods that implement the various embodimentsof the invention discussed above. The computer-readable medium or mediacan be transportable, such that the program or programs stored thereoncan be loaded onto one or more different computers or other processorsto implement various aspects of the present invention as discussedabove.

It should be understood that the term “program” is used herein in ageneric sense to refer to any type of computer code or set ofinstructions that can be employed to program a computer or otherprocessor to implement various aspects of the present invention asdiscussed above. Additionally, it should be appreciated that accordingto one aspect of this embodiment, one or more computer programs that,when executed, perform methods of the present invention need not resideon a single computer or processor, but may be distributed in a modularfashion amongst a number of different computers or processors toimplement various aspects of the present invention.

Various aspects of the present invention may be used alone, incombination, or in a variety of arrangements not specifically discussedin the embodiments described in the foregoing, and the aspects of thepresent invention described herein are not limited in their applicationto the details and arrangements of components set forth in the foregoingdescription or illustrated in the drawings. The aspects of the inventionare capable of other embodiments and of being practiced or of beingcarried out in various ways. Various aspects of the present inventionmay be implemented in connection with any type of network, cluster orconfiguration. No limitations are placed on the network implementation.Accordingly, the foregoing description and drawings are by way ofexample only.

Use of ordinal terms such as “first”, “second”, “third”, etc., in theclaims to modify a claim element does not by itself connote anypriority, precedence, or order of one claim element over another or thetemporal order in which acts of a method are performed, but are usedmerely as labels to distinguish one claim element having a certain namefrom another element having a same name (but for use of the ordinalterm) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limiting. The use of“including,” “comprising,” or “having,” “containing,” “involving,” andvariations thereof herein, is meant to encompass the items listedthereafter and equivalent thereof as well as additional items.

What is claimed is:
 1. At a first computing device in a distributednetwork environment, a method of authenticating the first computingdevice to a second computing device using a mobile module of a thirdcomputing device which is connected to the first computing device, themethod, which is performed by the first computing device, comprising:obtaining a network security token to establish transport level securecommunication between the first computing device and a second computingdevice by performing the following: sending a request for the networksecurity token to the mobile infrastructure via the second computingdevice; obtaining at the first computing device a response from themobile module in response to a network level challenge that is issuedfor the request; the first computing device using the response from themobile module to generate and send a request security token responsefrom the first computing device to the mobile infrastructure; receivingat the first computing device a network security token corresponding tothe request security token response which include encrypted sessionkeys; sending from the first computing device the encrypted session keysto the mobile module; receiving at the first computing deviceunencrypted session keys from the mobile module; and the first computingdevice using the network security token to obtain a user security tokenwhich is subsequently used to obtain a service token.
 2. The methodrecited in claim 1, wherein the first computing device using the networksecurity token to obtain the user security token includes: sending arequest for a user security token to the mobile infrastructure via thesecond computing device; receiving at the first computing device achallenge from the mobile infrastructure; sending from the firstcomputing device the received challenge to a mobile module of the thirdcomputing device; receiving at the first computing device a request foruser credentials from the mobile module; at the first computing deviceprompting the user for and receiving the credentials; sending from thefirst computing device the credentials to the mobile module; receivingat the first computing device a challenge response sent from the mobilemodule; in response to the challenge, creating at the first computingdevice a request user security token response, and signing or encryptingthe response with the network security token; sending the request usersecurity token response from the first computing device to the mobileinfrastructure; receiving at the first computing device a user securitytoken from the mobile infrastructure that includes new encrypted userkeys; sending from the first computing device the new encrypted userkeys to the mobile module; and receiving at the first computing devicenew unencrypted user keys from the mobile module, which correspond tothe user security token.
 3. The method recited in claim 2, wherein thefirst computing device uses the user security token to obtain theservice token by performing the following: at the first computingdevice, signing or encrypting one or more requests for a service tokenwith the new unencrypted user keys of the user security token; sendingthe one or more requests signed or encrypted with the new unencrypteduser keys from the first computing device to a computing devicecontaining the service token; in response to the one or more requests,the first computing device receiving the service token from thecomputing device containing the service token.
 4. The method of claim 3,wherein the second computing device is the computing device containingthe service token.
 5. The method of claim 4, wherein the method furtherincludes the first computing device using the service token to obtainone or more goods or services.
 6. The method of claim 2, wherein themethod further includes sending the credentials to the mobile moduleafter first signing the credentials with the unencrypted session keyscorresponding to the network security token.
 7. The method of claim 1,wherein the method further includes sending the request security tokenresponse only after it is first signed by the mobile module.
 8. Themethod of claim 1, wherein the mobile module is a subscriber identitymodule (SIM) card.
 9. The method of claim 1, wherein at least one of theone or more service tokens includes information that identifies themobile module.
 10. The method of claim 1, wherein at least one of theone or more service tokens includes information regarding an identity ofthe user.
 11. The method of claim 1, wherein at least one of the one ormore service tokens includes information that verifies the ability ofthe user to pay for services provided by a third party server.
 12. Oneor more computer storage device having stored computer-executableinstructions which when executed by a processor perform a method at afirst computing device in a distributed network environment, forauthenticating the first computing device to a second computing deviceusing a mobile module of a third computing device which is connected tothe first computing device, wherein the method includes: obtaining anetwork security token to establish transport level secure communicationbetween the first computing device and a second computing device byperforming the following: sending a request for the network securitytoken to the mobile infrastructure via the second computing device;obtaining at the first computing device a response from the mobilemodule in response to a network level challenge that is issued for therequest; the first computing device using the response from the mobilemodule to generate and send a request security token response from thefirst computing device to the mobile infrastructure; receiving at thefirst computing device a network security token corresponding to therequest security token response which include encrypted session keys;sending from the first computing device the encrypted session keys tothe mobile module; receiving at the first computing device unencryptedsession keys from the mobile module; and the first computing deviceusing the network security token to obtain a user security token whichis subsequently used to obtain a service token.
 13. The one or morecomputer storage device recited in claim 1, wherein the first computingdevice using the network security token to obtain the user securitytoken includes: sending a request for a user security token to themobile infrastructure via the second computing device; receiving at thefirst computing device a challenge from the mobile infrastructure;sending from the first computing device the received challenge to amobile module of the third computing device; receiving at the firstcomputing device a request for user credentials from the mobile module;at the first computing device prompting the user for and receiving thecredentials; sending from the first computing device the credentials tothe mobile module; receiving at the first computing device a challengeresponse sent from the mobile module; in response to the challenge,creating at the first computing device a request user security tokenresponse, and signing or encrypting the response with the networksecurity token; sending the request user security token response fromthe first computing device to the mobile infrastructure; receiving atthe first computing device a user security token from the mobileinfrastructure that includes new encrypted user keys; sending from thefirst computing device the new encrypted user keys to the mobile module;and receiving at the first computing device new unencrypted user keysfrom the mobile module, which correspond to the user security token. 14.The one or more computer storage device recited in claim 13, wherein thefirst computing device uses the user security token to obtain theservice token by performing the following: at the first computingdevice, signing or encrypting one or more requests for a service tokenwith the new unencrypted user keys of the user security token; sendingthe one or more requests signed or encrypted with the new unencrypteduser keys from the first computing device to a computing devicecontaining the service token; in response to the one or more requests,the first computing device receiving the service token from thecomputing device containing the service token.
 15. The one or morecomputer storage device of claim 14, wherein the second computing deviceis the computing device containing the service token.
 16. The one ormore computer storage device of claim 15, wherein the method furtherincludes the first computing device using the service token to obtainone or more goods or services.
 17. The one or more computer storagedevice of claim 13, wherein the method further includes sending thecredentials to the mobile module after first signing the credentialswith the unencrypted session keys corresponding to the network securitytoken.
 18. The one or more computer storage device of claim 12, whereinthe method further includes sending the request security token responseonly after it is first signed by the mobile module.
 19. The one or morecomputer storage device of claim 12, wherein the mobile module is asubscriber identity module (SIM) card.
 20. A computing systemcomprising: at least one processor; and one or more computer storagedevice having stored computer-executable instructions which whenexecuted by the at least one processor perform a method at the computingsystem for authenticating the computing system to another computingdevice using a mobile module of a mobile computing device which isconnected to the computing system, wherein the method includes:obtaining a network security token to establish transport level securecommunication between the computing system and said other computingdevice by performing the following: sending a request for the networksecurity token to the mobile infrastructure via the other computingdevice; obtaining at the computing system a response from the mobilemodule in response to a network level challenge that is issued for therequest; the computing system using the response from the mobile moduleto generate and send a request security token response from thecomputing system to the mobile infrastructure; receiving at thecomputing system a network security token corresponding to the requestsecurity token response which include encrypted session keys; sendingfrom the computing system the encrypted session keys to the mobilemodule; receiving at the computing system unencrypted session keys fromthe mobile module; and the computing system using the network securitytoken to obtain a user security token which is subsequently used toobtain a service token.